Lambda the Ultimate

Gilad Bracha:

Basically, it will be a lot like invokevirtual (if you don’t know what that is, either open a JVM spec and find out, or stop reading). The big difference is that the verifier won’t insist that the type of the target of the method invocation (the receiver, in Smalltalk speak) be known to support the method being invoked, or that the types of the arguments be known to match the signature of that method. Instead, these checks will be done dynamically.

There will probably be a mechanism for trapping failures (a bit like messageNotUnderstood in Smalltalk).

The goal: Improve the support for dynamically type checked languages on the JVM, of course.

I'd like the thank everyone who took the time to offer suggestions and ideas.

Because of the importance of this issue, I am posting this as a new home page item.

Reading the discussion, it seems some things are in need of clarification. Lambda the Ultimate was created by me and by the LtU community to serve our needs and interests, and though these are quite broad, LtU was never intended to be the single programming language site on the net, nor will it ever attempt to be one. There are many other sites, and if the style of discussion here seems too highbrow for what one has in mind, other sites are available. In the same vein, LtU cannot replace language specific sites, and is intended to explore topics that are of general interest. Code examples are more than welcome, provided they are enlightening and instructional, we were never only about theory.

LtU has large and vibrant community, with diverse interests and skills. The main thing uniting us is our interest in programming languages. If your interests are sincere, you belong here. As you become part of the community, you naturally have a larger impact on the topics under discussion. Luke, for example, is a long time reader and contributor and yet he asks whether specific subjects are appropriate. If Luke finds a topic to be of interest to the community, I for one would be happy to learn about it. The same goes for the other editors, and most long time readers who aren't editors as well. Luke and others ask me (or other members via the forum) about items they are unsure of - because they care about the site and the community. They are genuine members of the community. Sincerity is key.

This is part of the culture of LtU, and I don't think technical solutions are needed or helpful in maintaining it. I am also unsure how to explain this culture in a FAQ, but we will give it a shot, since many mentioned this as a problem. Several good suggestions were made in the previous thread, and we may lift them and create a more detailed FAQ.

It seems most members like LtU the way it is (or used to be), and we should try to make as little a change as possible, to counterbalance the recent problems.

Now for more specific measures:

1. Signatures will be eliminated - effective immediately. Personally, I also don't like pseudonyms, but I will not mandate this preference since people raised good counter arguments when this was last discussed.

2. I will be more pro-active when it comes to deleting posts that don't seem sincere. Most responses in the previous thread seemed to be ok with that. I might ask other editors to assist, since I don't have the time to do it myself. Voting seems too complicated, and I don't think it is appropriate for the kinds of problem we had in mind.

3. Banning - it seems no one is really against banning real trolls. I am not sure how to do this (since users can create new accounts), but I think we will keep the option to do this, and use it if we find it appropriate. I think I will not ban users before discussing the matter with at least one other editor.

4. We need to add links to various other PL sites (comp.lang.misc, C2, etc.) to the FAQ.

5. The FAQ links to the Getting Started thread, we should link to other introductory threads. If you have suggestions on what to include, use the comments to tell us.

6. We are in the process of starting a LtU-Wikipedia about PLs. This will take some time but will also help.

7. Regulars should be more pro-active in politely letting newcomers know when they post items that aren't appropriate. If you, as a LtU regular, are unsure about your objection, it is best to mention it publicly. Thanks!

Finally let me end by reminding everyone that posting here isn't a right, it's a privilege. The LtU community, even though ad hoc and without institutions, is strong enough a community to maintain the atmosphere of polite and sincere discussion we are used to having. However, in cases where it proves necessary, we will remove topics and posters that undermine this goal.

Propositional Satisfiability and Constraint Programming: A comparative Survey. Lucas Bordeaux; Youssef Hamadi; L. Zhang.

Propositional Satisfiability (SAT) and Constraint Programming (CP) have developped as two relatively independent threads of research, cross-fertilising occasionally. These two approaches to problem solving have a lot in common, as evidenced by similar ideas underlying the branch and prune algorithms which are most successful at solving both kinds of problems. They also exhibit differences in the way they are used to state and solve problems, since SAT's approach is in general a black-box approach, while CP aims at being tunable and programmable. This report overviews the two areas in a comparative way, emphasizing the similarities and differences between the two and the points where we feel that one technology can benefit from ideas or experience acquired from the other.

This is a long and detailed survey, that may serve as an introduction to the two fields.

How useful these searching strategies are as programming language constructs is open to debate, of course.

Hooray for the winners and judges!!
Link

LtU is primarily a weblog dedicated to posting links to interesting projects, research papers, and programming languages related news, by contributing editors who can post to the home page - items intended to be discussed in the comments section.

Editors (as opposed to guest bloggers who are asked to join us because of their contributions to the field) are encouraged not to post about their own work, nor to post rants and opinions to the home page.

This allowed LtU to maintain a very high standard of quality for the news items posted to the home page, and resulted in deep and informed discussions.

As LtU grew, the attached forum became more and more active. This level of activity, while exhilarating, poses some predictable problems. Too many of the problems that plague other forums related to programming languages, such as religious wars about typing, Microsoft bashing, and possible trolls are becoming a real issue for LtU. Newcomers, attemtping to learn their way into the field, will always be welcome on LtU. Trolls abuse this by asking "naive" questions, and arguing positions that only serve to confuse rather than inform.

A few LtU regulars voiced their concern. I agree: I have been following the discussion group much less closely myself, recently, because of these issues.

LtU wasn't intended to be the only web forum on programming languages, nor do I intend to manage a multitude of forums for all tastes and styles. LtU is intended for the discussion of items thought to be news worthy by the contributing editors. Short topical messages to the forum were ok, as were off topic messages, when LtU was small and not well known. It seems that we as a community need to decide how to keep the original style and commitment to civilized, informed and professional discussion.

Some of the suggestions I received regarding possible modifications to the site and its policies:

1. Closing commenting entirely. I think this is too harsh, since the discussions often contain great ideas and suggestions.

2. Eliminating the option to create new threads in the forum, thus only allowing contributing editors to set the agenda, so to speak.

3. Establishing some sort of comment moderation. I think this is too problematic and requires to much work from the volunteers running the site (including myself).

4. Banning users who use LtU to advertise, post trolls etc. I don't like banning, but I also don't want trolls to alienate long time members. We aren't sure whether there are (non-troll) readers who feel strongly that we should not ban people. How do we decide on policy, as regards banning?

5. Eliminating user signatures (which are appended to all their posts), since they seem to mostly add noise.

My hope, originally, was that the norms of behaviour here will be enough to ensure newcomers understand and maintain the LtU style and unwritten code of behaviour. Perhaps waiting for this to happen is still the best option. We may decide to not let trolls and such dictate our policies, deciding that we can live with them even though they are irritating.

I'd like to hear your opinion. Especially if you are a long time reader and contributor.

Some rules of behaviour are obvious, yet seem to require reiterating and strengthening: personal slurs and attacks and advertisements will not be tolerated. They will be deleted without warning, and repeat offenders will be banned from the site.

It rapidly became clear that a single language runtime is too limited for general applications ... as a minimum we needed both a linear-flow language and a recursive tree composition language ... while declarative languages are excellent for rapid assembly of XML operations, they are terrible for expressing business logic and logical flow-control ... Our other declarative language is XML Recursion Language (XRL). XRL is like XInclude with services, in which inclusion references fire service invocations into the URI address space in order to recursively compose an XML document. XRL is an elegant and powerful way of building XHTML applications ... The active URI, in combination with the local NetKernel environment, is a functional program - Introducing NetKernel.

Main site; Tour.

It's another XML pipeline (there's a Freshmeat project that lets Coccoon apps run in NetKernel), apparently from HP, which might interest people here.

Cedric Fournet; Andrew D. Gordon; Sergio Maffeis. A Type Discipline for Authorization Policies. ESOP 2005.

Distributed systems and applications are often expected to enforce high-level authorization policies. To this end, the code for these systems relies on lower-level security mechanisms such as, for instance, digital signatures, local ACLs, and encrypted communications. In principle, authorization specifications can be separated from code and carefully audited. Logic programs, in particular, can express policies in a simple, abstract manner. We consider the problem of checking whether a distributed implementation based on communication channels and cryptography complies with a logical authorization policy. We formalize authorization policies and their connection to code by embedding logical predicates and claims within a process calculus. We formulate policy compliance operationally by composing a process model of the distributed system with an arbitrary opponent process. Moreover, we propose a new dependent type system for verifying policy compliance of implementation code. Using Datalog as an authorization logic, we show how to type several examples using policies and present a general schema for compiling policies.

Another "extreme" use of static typing...

RIFE is an open source Java web application framework which allows web applications to benefit from first-class continuations. Now, RIFE's pure Java continuation engine, which uses Java bytecode manipulation to implement continuations, has been extracted into a standalone Java library:

Announcing RIFE/Continuations, pure Java continuations for everyone

The immediate motivation for doing this was to achieve support for continuations in the WebWork application framework, which now supports them it its latest beta.

Along similar lines, there's also the Apache Jakarta project, Commons Javaflow.

From a language design perspective, it's interesting to see features like this being introduced without modifying the language implementation. Other examples of continuations being added to languages, as in Stackless Python and the Javascript implementation Rhino with Continuations, have been done by forking the language implementation, which of course isn't as practical in Java's case.

Since Erik's got us on a VB kick these days, here are a couple recent videos from Microsoft's Channel 9 on current and future developments of the language:

Dynamic Programming in VB - more on the "static typing where possible, dynamic typing where necessary" theme.

VB Language Futures - ideas for the future of VB, including some new syntactic sugar, type inference, and all this query stuff.

At a glance, the dynamic interfaces make me think of Semantic Casts: Contracts and Structural Subtyping in a Nominal World. I wonder if there's any relevance.

XQuery Implementation in a Relational Database System. VLDB 2005.

This paper describes the experiences and the challenges in implementing XQuery in Microsoft’s SQL Server 2005. XQuery language constructs are compiled into an enhanced set of relational operators while preserving the semantics of XQuery. The query tree is optimized using relational optimization techniques, such as cost-based decisions, and rewrite rules based on XML schemas.

Quite detailed. Section 6 covers optimization, and coupled with section 7 discussing related work, might be enough for those not really interested in all the intricate details of SQL Server's implementation of XQuery.